Conditional application invocation in a wireless device

ABSTRACT

Disclosed embodiments include a mobile communication device that automatically receives signals indicating predetermined events, and automatically takes actions in response to the events. The actions include executing one or more software applications on the device. The applications include native applications and downloaded applications that are individually configured.

RELATED APPLICATIONS

The present application is related to U.S. application Ser. No. ______, (Attorney Docket No. 101948087US) entitled, “Automated Device Behavior Management Based on Network Charging and Rating Conditions” by Christopher White; U.S. application Ser. No. ______, (Attorney Docket No. 101948088US) entitled, “Automated Device Behavior Management Based on Preset Preferences” by Christopher White: and U.S. application Ser. No. ______, (Attorney Docket No. 101948089US) entitled, “Control of Security of Ease-of-Use Sensitivity for a Wireless Communication Device: by Christopher White, all filed on the same day herewith and commonly assigned to AT&T Wireless Services, Inc.

BACKGROUND

The disclosed embodiments relate to configuring a wireless device to automatically invoke various applications based on the occurrence of events or conditions.

Current wireless communication devices such as cellular phones and various handheld devices typically include one or more “native” application programs stored on the device by the manufacture to perform specific functions. For example, cellular phones have a call controller native application that receives and recognizes keypad inputs and responds appropriately. If the keypad entry is a valid phone number, the call controller responds by attempting to establish a communication channel with the device identified by the number.

At present, remote execution of applications on a device is done by determining, at the provider side, what the device is to do, under what conditions the device is to do it, and what applications will be executed. Currently, a signal can be sent to a device to cause the device to take a predefined action. A small subset of these actions can be invoked remotely by the user or the wireless service carrier, or provider. For example, a short message service (“SMS”) message can invoke a particular program.

As a more detailed example, some handheld devices can receive a signal that causes the device to notify the user a certain stock price has been reached. This is an example of a specific application on the wireless device performing a particular action in response to a predetermined signal. On the provider side, in response to an event (the stock reaching a predetermined price), a provider merely creates a text message and sends it to the device for display. The human user must read the message and decide how to act on it.

The ability of the user to configure automatic device behavior and the ability to remotely invoke application on a device is very limited. Currently, remote device configuration is typically done by the provider at a level below the application level. Another limitation of the current server-side remote device application invocation is the provider must know what applications are on the device and how each is configured. This does not usually present a problem because most devices, for example most cellular phones, do not store applications other than the native applications installed by the provider. In the near future, most or all cellular phones and other mobile devices will support user-downloaded applications from various third parties. Each of these downloaded applications must be configured individually by the user. Each user may configure an application differently on a device. The variety of configurations is potentially unlimited. Therefore, the current model of provider remote invocation of device behavior becomes unworkable with downloadable applications because the provider no longer knows what the device is capable of, or exactly how it performs tasks it is capable of.

Overall, there is a need for an improved user-configurable wireless device that recognizes events and conditions specified by the user and automatically performs a series of user user-configured actions using one or more user-configured applications.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram of an embodiment of a wireless communication system.

FIG. 2 is a flow diagram of one embodiment of device configuration.

FIG. 3 is a flow diagram of one embodiment of remote application invocation.

FIG. 4 is a diagram of an embodiment of a wireless communication device.

FIG. 5 is a diagram of an embodiment of a Java application management service (“JAMS”).

FIG. 6 is another diagram of an embodiment of a wireless communication device.

DETAILED DESCRIPTION

Embodiments of the invention, described below, include a mobile communication device that automatically receives signals indicating events, and automatically takes actions in response to the events. The actions include executing one or more software applications on the device. The applications include native applications and downloaded applications that are individually configured. The events and the actions taken are configurable by a user of the device. In one embodiment, the user configures preferences that are stored by a wireless communication service carrier or provider. The provider remotely updates configuration data in the device transparently to the user. In an embodiment, the configuration data includes a list of events recognized by the device, and a list that relates those events to applications to be executed in response to the events. After the configuration data is updated, the wireless device communicates with the provider network such that each of the recognized events automatically causes desired device behavior without intervention by the user. Depending on the class of the device, communication and device behavior as described herein can occur during, or not during, a voice connection. In the latter case, the communication is queued until the voice connection is closed. The communication and behavior does not occur when the device is powered down.

FIG. 1 is a diagram of an embodiment of a wireless communication system 100. The system 100 is arbitrarily divided into two areas. Area 104 includes equipment and applications (“provider equipment”) typically provided and maintained by a wireless communication service provider, such as a cellular phone service provider. Area 102 includes equipment and applications (with the exception of radio tower 116) that are typically not provided or maintained by the provider, but are designed to communicate on a wireless network with the provider equipment. System 100 is an example of one arrangement of elements, but others are possible. A cellular phone service provider is one example of a provider, but other examples include any wireless service provider that provides wireless communication capabilities through a user device over a wireless network. For example, service providers that support personal digital assistants (“PDAs”) are also providers for purposes of the embodiments described.

The area 104 includes various elements useful to illustrate embodiments. Many typically known elements of provider equipment are not shown because they do not add to the understanding of the embodiments. Provider applications 106 are software applications that maintain and administer the network. For example, the applications 106 include billing applications, performance monitoring applications, and many more. The applications 106 include applications that track user accounts, typically designated by a responsible billing party. The account may include one user with one device, or a group of many users each with a device. For example, some enterprises provide groups of employees with devices for limited or unlimited use in the course of employment.

The area 104 further includes a database or databases 108 and 110. The databases 108 and 110 are shown separately to distinguish the types of data stored, but could be one physical entity or more than two physical entities. The database 110 is a billing database that stores data used by the provider to generate bills for an account. Billing data includes minutes used at different rates, and the number of minutes allowed in a time period before special rates apply, for example.

A user preferences database 108 stores a user's choices regarding what events the user would like the device to be automatically notified of. The user preference database also includes actions the user would like the device to take when an event occurs. One example is the device automatically blocking all outbound calls upon the transition from off-peak billing rate time to on-peak billing rate time.

A short message service controller (“SMSC”) 114 manages short messaging, including receiving/sending, generating, and encoding/decoding SMS messages. The wireless communication device 118 communicates over the wireless network using radio towers such as radio tower 116 in the known manner. An event manager 112 recognizes events and sends a message to the SMSC in response.

A user 120 of a wireless communication device 118 may configure the user preferences by accessing a dedicated provider configuration application (one of the applications 106). The applications 106 may be accessed using the device 118, or using a personal computer 122 to access the application 106 via the Internet 124. The user preferences are developed by the provider configuration application based on user inputs and downloaded from the provider to the device 118. The device 118 includes downloaded applications (not shown in FIG. 1) that may come from the provider or any third party. Downloaded applications from the provider may be configured in the same way as preferences, as described. Downloaded applications from third parties may be configured in any way dictated by the third party source. The provider has no knowledge of the configuration of the third party downloaded applications or their individual configurations. The user 120, however, knows which downloaded applications are present on the device 118 and how they are configured to behave. The user 120 can therefore configure the user preferences accordingly. For example, the user may configure the user preferences such that a downloaded email application only sends or receives emails during an off-peak period.

FIG. 2 is a flow diagram illustrating an embodiment of the device 118 configuration. Referring to FIG. 1 and FIG. 2, at 202 the user individually configures the downloaded applications on the device 118. Then, the user configures the user preferences at 204, and the user preferences are stored (at 206) in the database 108. When a new user configuration is stored for an account, a message is sent to the short message service controller (“SMSC”) 114 at 208. At 210, the SMSC 114 generates an encoded SMS message to the device 118 that indicates a new user configuration is available to be downloaded. At 212, the device 118 opens a communication channel to the provider equipment 104 to retrieve the new configuration data. In one embodiment, the encoded message reaches the device 118, indicating that the device 118 is receiving a general packet radio service (“GRPS”) signal. In one embodiment, the condition “Home GPRS Available” is in the signal. The device 118 invokes a Java application management service (“JAMS”, described further below), which looks for applications with a “Refresh when new data connection becomes available” flag set. The indicated applications start and perform data refreshes. The user need not take any actions. The new configuration data is received, and a condition catalog and a condition registry (described below) are updated at 214.

For the purpose of device 118 configuration, out-of-band signals are exchanged between the device 118 and the provider equipment, although in-band signaling could be used. These signals may be exchanged via a hypertext transfer protocol (“HTTP”) connection, a wireless application protocol (“WAP”) connection, or any other wireless communication method.

FIG. 3 is a flow diagram illustrating an example of automatic conditional application invocation. Referring to FIG. 1 and FIG. 3, At 302, a message is sent to the event manager 112 to indicate that a specific event has taken place. As one example, the billing database 110 sends a message to the event manager 112 that indicates a minute “bucket” for the account has only ten more minutes left in it. At 304, the event manager 112 sends a message to the SMSC 114 requesting that an encoded message be generated. The SMSC encodes the message and sends it to the device 118 at 306. At 308, the device 118 receives and decodes the message, and sends a return message to retrieve the event from the event manager 112. At 310, the device 118 receives the event from the event manager 112 and processes the event using an event registry as described below. In an alternative embodiment, the SMS message sent to the device on the occurrence of an event includes the information regarding the event. In this embodiment, therefore, the device does not retrieve the event from the event manager.

FIG. 4 is a block diagram of an embodiment of the device 118. The device 118 includes native applications 404, and downloaded applications 408. Radio 402 includes the hardware and software required to communicate over the wireless network. A JAMS 406 includes Java programs and Java program management capability.

FIG. 5 is a block diagram of the JAMS 406 in one embodiment. The JAMS 406 includes downloaded Java applications 502 designated A, B, C, and D. The number of downloaded Java applications shown is an arbitrary example. The actual number of downloaded Java applications stored can be greater or less than four, and is only limited by storage capacity. The JAMS 406 also stores an event catalog 504 and an event registry 506.

FIG. 6 is another block diagram of the JAMS 406 showing more detail of the event catalog 504 and the event registry 506. The event catalog 504 includes a list of events recognized by the device 118. The event catalog is populated when the user downloads new user preferences as previously described. Some examples of events are the transition from off-peak time to on-peak time and the reverse, the transition from being on the network to roaming and the reverse, and the occurrence of a new bucket for the account. The events shown are a subset of possible events that can be recognized by the device 118. The event registry 506 includes a list of the events recognized by the device 118 for each event, and which downloadable Java applications (A, B, C, and/or D) should be executed when the event occurs. For example, when event 1 (off-peak to on-peak transition) occurs, application A and C are executed. Application A may be an application that generates a user message that the transition is occurring, while application C may block outgoing calls automatically (subject to user override). In other embodiments, the applications listed in the event registry include native applications as well as downloaded applications. In other embodiments, the event catalog and event registry do not reside on the JAMS, but reside elsewhere on the device.

Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” “above”, “below,” and words of similar import, when used in this application, shall refer to this application as a whole and not to any particular portions of this application.

The above detailed descriptions of embodiments of the invention are not intended to be exhaustive or to limit the invention to the precise form disclosed above. While specific embodiments of, and examples for, the invention are described above for illustrative purposes, various modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. For example, while steps are presented in a given order, alternative embodiments may perform routines having steps in a different order. The teachings of the invention provided herein can be applied to other systems, not necessarily only wireless communication system described herein. The various embodiments described herein can be combined to provide further embodiments.

These and other changes can be made to the invention in light of the above detailed description. In general, the terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification, unless the above detailed description explicitly defines such terms. Accordingly, the actual scope of the invention encompasses the disclosed embodiments and all equivalent ways of practicing or implementing the invention under the claims.

While certain aspects of the invention are presented below in certain claim forms, the inventors contemplate the various aspects of the invention in any number of claim forms. For example, while only one aspect of the invention is recited as embodied in a computer-readable medium, other aspects may likewise be embodied in a computer-readable medium. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the invention. 

1. A wireless communication system, comprising: wireless communication provider equipment, comprising a storage device that stores provider software applications and data, including an event manager application and a short message service controller (SMSC) application; a wireless communication device coupled to the provider equipment, comprising, more than one software application, including native applications and downloaded applications, wherein the downloaded applications are individually configured by a wireless device user; an event catalog that stores a list of user-specified events; and an event registry that stores relationships between events and actions, wherein the wireless device receives notification of an event from the provider equipment and automatically performs one or more actions using one or more software applications based on predefined user preferences. 2-46. (canceled) 